Usenet 1993 July

home *** CD-ROM | disk | FTP | other *** search

/ Usenet 1993 July / InfoMagic USENET CD-ROM July 1993.ISO / answers / motif-faq / part4 < prev next >

Wrap

Text File | 1993-06-30 | 59.0 KB | 1,396 lines

Newsgroups: comp.windows.x.motif,news.answers,comp.answers Path: senator-bedfellow.mit.edu!enterpoop.mit.edu!spool.mu.edu!sdd.hp.com!saimiri.primate.wisc.edu!caen!batcomputer!munnari.oz.au!newshost.anu.edu.au!csc.canberra.edu.au!news From: jan@ise.canberra.edu.au (Jan Newmarch) Subject: Motif FAQ (Part 4 of 5) Message-ID: <1993Jul1.011200.28031@csc.canberra.edu.au> Followup-To: comp.windows.x.motif Keywords: FAQ question answer Sender: news@csc.canberra.edu.au Reply-To: jan@ise.canberra.edu.au (Jan Newmarch) Organization: University of Canberra Date: Thu, 1 Jul 93 01:12:00 GMT Approved: news-answers-request@MIT.Edu Expires: +1 months Lines: 1379 Xref: senator-bedfellow.mit.edu comp.windows.x.motif:18409 news.answers:9858 comp.answers:1163 Archive-name: motif-faq/part4 Last-modified: Wed July 1 1993 Version: 3.6 ----------------------------------------------------------------------------- Subject: 90) TOPIC: XMSTRING ----------------------------------------------------------------------------- Subject: 91) How can I get the Ascii text out of an XmString? Answer: To get the first line of text from a string created left-to-right char *str; XmString xmstr; /* stuff to create xmstr */ ... /* set str to point to the text */ XmStringGetLtoR(xmstr, XmSTRING_DEFAULT_CHARSET, &str); /* use the string */ ... /* and reclaim space */ XtFree(str); ----------------------------------------------------------------------------- Subject: 92) When can XmStrings used as resources be freed? Answer: The policy OSF have been trying to enforce is that if you set an XmString or XmStringTable resource, the application is responsible for freeing the XmStrings used because the widget makes a copy. If you get an XmString resource, then the application must free the value gotten. If you get an XmStringTable, then the application should NOT free the value gotten. If the application wants to manipulate it, it should make a copy first. This policy appears to be implemented progressively, so may be less true for Motif 1.0 than 1.1. ----------------------------------------------------------------------------- Subject: 93) Why doesn't XmStringGetNextSegment() work properly? Answer: The documentation in Motif 1.0 is in error. Instead of XmStringGetnextSegment(context, ...) XmStringContext * context; it should be XmStringGetnextSegment(context, ...) XmStringContext context; i.e. with no indirection. ----------------------------------------------------------------------------- Subject: 94)+ Why does using XmStringDraw cause a Bad Font error? [Last modified: May 93] Answer: From Thomas Berlage (berlage@gmdzi.gmd.de): You could call this a bug in Motif. You pass a GC to XmStringDraw, however, Motif wants to use the fonts from the font list to draw the string. Therefore it replaces the font of the GC temporarily with some fonts of its own as specified in the font list. In the end it tries to restore the old font of the GC. There comes the problem: If a GC uses the default font, the client side GC structure does not have a valid font id (that is the 0xffffffff you may see in the error message). Motif tries to restore this invalid id at the end. The workaround is: Before drawing with XmStringDraw, set the font id of the GC to any valid font id, for example using XSetFont (display, gc, XLoadFont (display, "fixed")); ----------------------------------------------------------------------------- Subject: 95) TOPIC: DIALOGS ----------------------------------------------------------------------------- Subject: 96) How do I stop my dialog disappearing when I press the help button? Answer: Bulletin board has the resource autoUnmanage which defaults to True. This unmanages the widget when any button child is activated - including the help button. Set this to False to stop it disappearing. Note that you then have to unmanage the bulletin board yourself when any other button is activated. ----------------------------------------------------------------------------- Subject: 97) How do I make my own dialog? I want a dialog with my own set of buttons that stretch and shrink like the ones in e.g. PromptDialog and its own contents. Answer: Start off with say a PromptDialog. Unmanage the buttons you don't want or manage the Apply button if you want another. Unmanage the other bits of the selection box you don't want. You can add another WorkArea child to the selection box for any extra stuff you want. /* Copyright 1990, Kee Hinckley and Brian Holt Hawthorne */ /* Permission granted for any use, provided this copyright */ /* notice is maintained. */ /* Create a dialog box */ argcount = setArgs(&args, XmNautoUnmanage, False, NULL); SomeDialog = XmCreatePromptDialog(mainShell, "someDialog", args, argcount); /* Now get rid of the things we don't want */ child = XmSelectionBoxGetChild(SomeDialog, XmDIALOG_SELECTION_LABEL); XtUnmanageChild(child); child = XmSelectionBoxGetChild(SomeDialog, XmDIALOG_TEXT); XtUnmanageChild(child); /* set the callbacks, and make sure the buttons we want are there */ child = XmSelectionBoxGetChild(SomeDialog, XmDIALOG_OK_BUTTON); XtAddCallback(child, XmNactivateCallback, callSomeFunc, someArg); XtAddCallback(child, XmNactivateCallback, unManage, SomeDialog); XtManageChild(child); child = XmSelectionBoxGetChild(SomeDialog, XmDIALOG_APPLY_BUTTON); XtAddCallback(child, XmNactivateCallback, callSomeFunc, someOtherArg); XtManageChild(child); child = XmSelectionBoxGetChild(SomeDialog, XmDIALOG_CANCEL_BUTTON); XtAddCallback(child, XmNactivateCallback, dialogUnmanage, SomeDialog); XtManageChild(child); /* Add a new work area. This can be any manager. */ child = XmCreateForm(SomeDialog, "someForm", NULL, 0); XtManageChild(child); /* and fill it up... */ something = doYourStuff(child); ----------------------------------------------------------------------------- Subject: 98) How come the title bars for my dialogs now have "_popup" or "<- popup" concatenated onto the widget name? Answer: Motif 1.0.3 (?) "fixed" things such that title bars without an explicit dialogTitle setting use the widget name with "_popup" or whatever added on. Set the dialogTitle resource explicitly if you don't want this new default naming scheme. ----------------------------------------------------------------------------- Subject: 99) How can I force a dialog window to display? I manage a "working" dialog, and do some computing, but the dialog window appears blank until the work has finished. How can I force it to be displayed? Answer: Use this. (David Brooks, Systems Engineering, Open Software Foundation) /* * This procedure will ensure that, if a dialog window is being mapped, * its contents become visible before returning. It is intended to be * used just before a bout of computing that doesn't service the display. * You should still call XmUpdateDisplay() at intervals during this * computing if possible. * * The monitoring of window states is necessary because attempts to map * the dialog are redirected to the window manager (if there is one) and * this introduces a significant delay before the window is actually mapped * and exposed. This code works under mwm, twm, uwm, and no-wm. It * doesn't work (but doesn't hang) with olwm if the mainwindow is iconified. * * The argument to ForceDialog is any widget in the dialog (often it * will be the BulletinBoard child of a DialogShell). */ ForceDialog(w) Widget w; { Widget diashell, topshell; Window diawindow, topwindow; Display *dpy; XWindowAttributes xwa; XEvent event; XtAppContext cxt; /* Locate the shell we are interested in. In a particular instance, you * may know these shells already. */ for (diashell = w; !XtIsShell(diashell); diashell = XtParent(diashell)) ; /* Locate its primary window's shell (which may be the same) */ for (topshell = diashell; !XtIsTopLevelShell(topshell); topshell = XtParent(topshell)) ; if (XtIsRealized(diashell) && XtIsRealized(topshell)) { dpy = XtDisplay(topshell); diawindow = XtWindow(diashell); topwindow = XtWindow(topshell); cxt = XtWidgetToApplicationContext(diashell); /* Wait for the dialog to be mapped. It's guaranteed to become so unless... */ while (XGetWindowAttributes(dpy, diawindow, &xwa), xwa.map_state != IsViewable) { /* ...if the primary is (or becomes) unviewable or unmapped, it's probably iconified, and nothing will happen. */ if (XGetWindowAttributes(dpy, topwindow, &xwa), xwa.map_state != IsViewable) break; /* At this stage, we are guaranteed there will be an event of some kind. Beware; we are presumably in a callback, so this can recurse. */ XtAppNextEvent(cxt, &event); XtDispatchEvent(&event); } } /* The next XSync() will get an expose event if the dialog was unmapped. */ XmUpdateDisplay(topshell); } ----------------------------------------------------------------------------- Subject: 100) How can I control placement of a popup widget? Each time a popup is created, it is placed in or over the middle of its parent. How can I make it obey the XmNx and XmNy values? Answer: Set the resource XmNdefaultPosition for the popup to False. Set the position of the popup by the resource values of XmNx and XmNy. Do not use XtMoveWidget, as this is for widget writers only. Here's a demo program from Dan Heller: /* Written by Dan Heller. Copyright 1991, O'Reilly && Associates. * This program is freely distributable without licensing fees and * is provided without guarantee or warranty expressed or implied. * This program is -not- in the public domain. This program is * taken from the Motif Programming Manual, O'Reilly Volume 6. */ /* map_dlg.c -- Use the XmNmapCallback to automatically position * a dialog on the screen. Each time the dialog is displayed, it * is mapped down and to the right by 200 pixels in each direction. */ #include <Xm/MessageB.h> #include <Xm/PushB.h> /* main() --create a pushbutton whose callback pops up a dialog box */ main(argc, argv) char *argv[]; { Widget toplevel, button; XtAppContext app; void pushed(); toplevel = XtVaAppInitialize(&app, "Demos", NULL, 0, &argc, argv, NULL, NULL); button = XtCreateManagedWidget("button", xmPushButtonWidgetClass, toplevel, NULL, 0); XtAddCallback(button, XmNactivateCallback, pushed, "Hello World"); XtRealizeWidget(toplevel); XtAppMainLoop(app); } /* callback function for XmNmapCallback. Position dialog in 200 pixel * "steps". When the edge of the screen is hit, start over. */ static void map_dialog(dialog, client_data, cbs) Widget dialog; XtPointer client_data; XmAnyCallbackStruct *cbs; { static Position x, y; Dimension w, h; XtVaGetValues(dialog, XmNwidth, &w, XmNheight, &h, NULL); if ((x + w) >= WidthOfScreen(XtScreen(dialog))) x = 0; if ((y + h) >= HeightOfScreen(XtScreen(dialog))) y = 0; XtVaSetValues(dialog, XmNx, x, XmNy, y, NULL); x += 200, y += 200; } /* pushed() --the callback routine for the main app's pushbutton. * Create and popup a dialog box that has callback functions for * the Ok, Cancel and Help buttons. */ void pushed(w, message) Widget w; char *message; /* The client_data parameter passed by XtAddCallback */ { Widget dialog; Arg arg[3]; XmString t = XmStringCreateSimple(message); extern void response(); XtSetArg(arg[0], XmNautoUnmanage, False); XtSetArg(arg[1], XmNmessageString, t); XtSetArg(arg[2], XmNdefaultPosition, False); dialog = XmCreateMessageDialog(w, "notice", arg, 3); XmStringFree(t); XtAddCallback(dialog, XmNmapCallback, map_dialog, NULL); XtManageChild(dialog); XtPopup(XtParent(dialog), XtGrabNone); } ----------------------------------------------------------------------------- Subject: 101) TOPIC: LANGUAGE BINDINGS ----------------------------------------------------------------------------- Subject: 102)* Is there a C++ binding for Motif? [Last modified: May 93] Answer: WWL is a library which defines C++ classes around X Toolkit Widgets. It is intended to simplify the task of C++ code writers when using the Toolkit by providing them with C++ objects, methods, type checking and several utility functions and classes. WWL has been tested under SunOs4.0.3 on sun3 and sun4, HPUX version 6.5 and 7.0 and Ultrix 4.0 on DECstation 3100 and 5000. It is expected to work on most other UNIX systems without too many problems. WWL is distributed as a tar file with all the source, documentation and example. The file is available using anonymous ftp from export.lcs.mit.edu (18.30.0.238 contrib/WWL-1.0.tar.Z lri.lri.fr (129.175.15.1) pub/WWL-1.0.tar.Z Answer: Rogue Wave Software has a C++ binding for Motif called View.h++. "View.h++ is a complete C++ interface to OSF/Motif. It doesn't just encapsulate it, but also includes a set of classes that provide a level of abstraction above Motif, thus simplifying menu and dialog creation, XmStrings, XmFontLists, etc. View.h++ supports a Model- View-Controller architecture, allowing for an even more object-oriented interface design. Includes a copy of Rogue Wave's Tools.h++ (foundation class library)" An object license is $795 "per seat" and a source code license is available for $2,995 "per seat." Rogue Wave also offers full support for View.h++. It is currently available for Sun Sparc, IBM RS/6000, HP 9000/700 series, SCO, Intel SVR4 ESIX. Please call for Silicon Graphics and DEC Ultrix status. For additional information, please contact: Matt Steinauer Rogue Wave Software, Inc. P.O. Box 2328 Corvallis, OR 97339 Phone: (503)754-3010 Fax: (503)757-6650 email: matts@roguewave.com Answer: From Andreas.Baecker@gmd.de: The GINA++ application framework contains an encapsulation of the OSF/Motif widg et classes and the Xt functionality into C++ classes. Its functionality is comparab le to that of the ULowell binding and the WWL. Additionally, it provides an easy-to -use framework for modeling new composite and primitive widget classes, plus an application framework similar to ET++ or MacApp build on top of it. The binding may be used independently from the framework classes. GINA++ is available through anonymous ftp from ftp.gmd.de [129.26.8.90] in the directory /gmd/ginaplus. Documentation about the Motif binding has been published in the X Resource Journ al, Number 2, 1992, Pages 106-130. The binding compiles with AT&T C++ 2.1 and GNU G+ + 2.1 and has been tested on SunOS 4.1.[12], X11R4 and Motif 1.1.3. Answer: Motif++ is a library that defines C++ class "wrappers" for the widgets defined in the OSF/Motif-1.1 widget library. Motif++ is also an application toolkit that provides other tools in conjunction with the widget wrapper classes. It has support for the Xbae widget set, plus other widgets. It has Imake support, and lots of test files. Motif++ is very similar to other public domain widget libraries such as The Widget Wrapper Library (WWL) and the C++ Binding for OSF/Motif developed at the Univeristy of Lowell. The two latter libraries are the result of much larger efforts. Availability: Anonymous ftp at decuac.dec.com (192.5.214.1), directory /pub/X11, file motif++.21.jul.92.tar.Z (855293 bytes). For more information, contact Ronald van Loon (rvloon@cv.ruu.nl) There is also mailing list for Motif++. Send e-mail to 'motif++-request@cv.ruu.nl' or 'rvloon@cv.ruu.nl' Answer: From Christian Goeller (goeller@seufert.de): We have a C++-class- library available. It's based on the Lowell-bindings and the work of Ronald van Loon (rvloon@cv.ruu.nl) and has a lot of (i hope) useful enhancements like containers, string-class (with Motif-support) and a graph-object. It should build completely with imake. You could ftp it from: Host: ftp.unibw-muenchen.de File: /pub/Motif-C++/v2.0.tar.Z Answer: Xm++ is a user interface framework for the C++ language built upon X11 and the X-Toolkit. It is designed to be a simple and intuitive programming interface to access the functionality of commonly used widgets. Xm++ was initially created for the Motif widget set, now support for the Athena widgets was added. Applications created with Xm++ run in both environments without changes, although many nice features are only available when using Motif. Xm++ is available on: export.lcs.mit.edu as: /contrib/Xm++.0.5.tar.Z Answer: The Solbourne OI toolkit (not Motif) also has a C++ binding. Answer: Liant have C++/Views. Answer: Quest have ObjectViews. Answer: Doug Young has written a book "Object Oriented Programming with C++ and Motif", Prentice-Hall ISBN 0-13-630252-1 about using C++ without requiring one of these toolkits. ----------------------------------------------------------------------------- Subject: 103) How can I have a C++ member function in a callback? [Last modified: December 92] Answer: Motif++ has a nice tutorial summarising mechanisms (this is available separately by email from Ronald van Loon (rvloon@cv.ruu.nl)). Doug Young's book deals extensively with one of these. The problem is that you don't get the object when you just use the function as a callback. You need to pass the object as a pointer through as the client_data. (use "this" as the client_data.) Then you can retrieve the object's address, and dereference from there. For example (Leo O'Donnell, Email: leo@avs.com), class MyButton { public: MyButton (Widget parent, const char *name) { _button = XtVaCreateManagedWidget ( name, xmPushButtonWidgetClass, parent, NULL, 0); XtAddCallback ( _button, XmNactivateCallback, &MyButton::activateCB, (XtPointer) this); } ~MyButton () { XtDestroyWidget (_button); } private: Widget _button; static void activateCB (Widget, XtPointer, XtPointer); }; void MyButton::activateCB (Widget, XtPointer thisBtn, XtPointer) { MyButton *btn = (MyButton *) thisBtn; // OK you've got the button instance now. Do some stuff with it! } ----------------------------------------------------------------------------- Subject: 104) Is there a Common Lisp binding for Motif? [Last modified: November 92] Answer: Try CLM. This includes a toolkit demon (in C) that takes a widget description (with callbacks), and forks a new process for each Motif application (which can be just a single menu, or whatever). Lisp can then continue running, with a separate lightweight lisp process handling the connection & callbacks. In North America & net environs, CLM-2.0beta is available from export.lcs.mit.edu. There is also CLIM, the Common Lisp Interface Manager. It provides access to motif and other toolkits and window systems. Here is some blurb: "Version 2.0 of the Common Lisp Interface Manager (CLIM) provides access to Motif. CLIM is the emerging standard for GUI development in Common Lisp. It offers a set of high-level facilities that enable rapid construction of user interfaces. Applications written using CLIM are portable across a variety of window systems and toolkits. For example, on the X window System, both Motif (OSF/Motif) and Openlook (OLIT) are supported. CLIM accesses the toolkit directly rather than emulating the look and feel." CLIM is available from a variety of Common Lisp vendors including Symbolics and Franz Inc. (info@franz.com). ----------------------------------------------------------------------------- Subject: 105)* Is there an Ada binding for Motif? [Last modified: July 93] Answer: Information on Ada bindings to Motif and other services (such as SQL and POSIX) can be found in a document maintained by the Ada Information Clearinghouse. The report can be found at host: ajpo.sei.cmu.edu loc: /public/ada-info/bindings.hlp.* access: anonymous ftp The suffix to the file (indicated above with an asterix) is the date of the latest update to the document. For example, the full name of the report updated on 14 June 1993 would be /public/ada-info/bindings.hlp.14Jun93. The file is ASCII. ------ Included File [...Excerpted from the AdaIC report bindings.hlp.14Jun93...] [...Updates can be found on ajpo.sei.cmu.edu, in the ...] [...file /public/ada-info/bindings.hlp.* The suffix ...] [...is always the date of the lastest version to the ...] [...report. ...] SECTION 12 X-Window System: OSF Motif and Open Look Available Ada Bindings 12.1 Description and Standardization Efforts The X-Window System is a network-transparent window system. It supports one or more screens containing overlapping windows or subwindows. X display servers distribute user input to and accept output requests from various client programs located either on the same machine or elsewhere in the network. OSF Motif (Open Software Foundation/Motif) is a graphical user interface from OSF that provides a Presentation Manager look and feel for applications running on any system with X Window version 11. It conforms to POSIX, ANSI C and X/Open's XPG3 standards. 12.2 Resources Available from Software Reuse Libraries/Repositories ASSET (Updated: November 1 992) The following information was taken in its entirety from the ASSET Library Repository Catalog, October 9, 1992. For more information on ASSET, see Appendix C. INTERFACE TO THE X WINDOW SYSTEM VERSION_NUMBER : 1.1 DEVELOPED_BY : SAIC RELEASE_DATE : 29-SEP-88 UNIQUE_IDENTIFIER : ASSET_A_240 ALTERNATE_NAME : SAICX2 ASSET_TYPE : SOFTWARE CODE FUNCTIONS : INTERFACE, BIND OBJECTS : ADA, X WINDOWS KEYWORDS : STANDARDS, BINDINGS COLLECTION : STARS FOUNDATIONS DISTRIBUTION : UNLIMITED DESCRIPTION : Interface to the X Window System An expression of the various concepts in Ada that provides a full, working Ada specification of the X Window system. Approved for public release; distribution is unlimited. 12.3 Products Available from Vendors Advanced Technology Center (Updated: November 1 992) The Advanced Technology Center (ATC) has an Ada binding to OSF Motif for their AXI~ product. AXI is currently available for most UNIX-based platforms, and is supported by Verdix, Meridian, and TeleSoft compilers. AXI is an Ada-to-X-Window System interface that provides the Ada programmer access to the 500+ functions, libraries, and procedures contained in the X library (Xlib), the X Toolkit (Xt), the X Extensible Library, the X Miscellaneous Utilities, the Motif widget set and the Motif Resource Manager. ATC is planning to develop an Ada binding to Open Look for AXI. For more information, contact:Larry Paulson, Advanced Technology Center, 22982 Mill Creek Drive, Laguna Hills, CA 92653, USA; Phone: 714-583-9119 Alsys, Inc. (Updated: May 1 992) The Alsys Ada Software Development Environment (Alsys's validated Ada compiler #901221W1.11103) for 386 UNIX is a production-quality Ada environment capable of handling very large Ada applications (over 500,000 lines of code). The product includes the Compiler; Multi-Library Environment, which provides a powerful and flexible way to manage Ada development effort and share program units; Binder, which supports unused subprograms elimination; High-and Low- Level Optimizers for improving code quality and performance; and Run-Time Executive for efficient support for executing Ada programs. Also included is the Developer's Toolset including: Ada Probe, a symbolic source level debugger and program viewer; AdaXref, a cross-reference generator; AdaMake, a recompilation aid; AdaReformat, a source reformatter. Alsys currently has Ada bindings to POSIX, X-Windows (OSF Motif), and the Generic Package of Elementary Functions for the Alsys Ada Software Development Environment, running on 386 UNIX 386/486-based machines supported as both host and target and running 386/ix or SCO UNIX. They are also planning a binding to SQL for 386/486 machines. Host/Target:386/486 PC under IX UNIX, 386/486 PC under SCO UNIX The Alsys Ada Software Development Environment for the IBM RS/6000 is a production-quality Ada environment capable of handling very large Ada applications. Hosted on and targeted to the IBM RS/6000 workstation under IBM's AIX operating system, the product includes the Compiler; Multi-Library Environment, which provides a powerful and flexible way to manage Ada development efforts and share program units; Binder; Run-Time Executive; and both a High and Low-Level Optimizer for improving code quality and performance. Also included is the Alsys Ada Toolset including Ada Probe, symbolic source level debugger and program viewer; AdaXref, cross-reference generator; AdaMake, recompilation aid; and AdaReformat, source reformatter. Alsys has bindings currently available to the Generic Package of Elementary Functions and to X-Windows (OSF Motif) for the Alsys Ada Development Environment for the IBM RS/6000 running on any RISC System/6000 machine as both host and target and running IBM's AIX operating system (Alsys's validated Ada compiler #910809W1.11195). Alsys also plans to develop a POSIX binding for the RS/6000. Host/Target:RISC System/6000 under AIX The Alsys Ada Software Development Environment for SPARC Workstations is a production-quality Ada environment capable of handling very large Ada applications. Hosted on any SPARC-based workstation under SunOS or SunView, the product helps you realize the full potential of Ada on SPARC machines. The product includes the Compiler (with High- and Low-Level Optimizers); Binder, which supports unused subprogram elimination; Multi-Library system (Family, Library, and Unit Managers) which provides a powerful and flexible way to manage Ada development efforts and share program units; AdaExec real-time executive, for complete and efficient support for executing Ada programs; and ISO-standard mathematical library. Also included is the Alsys Ada Toolset including AdaProbe, symbolic source level debugger and program viewer; AdaXref, cross-reference generator; AdaMake, recompilation aid; and AdaReformat, source reformatter. Bindings to the Generic Package of Elementary Functions and to OSF/Motif are currently available for the Alsys Ada Software Development Environment running on any SPARC-based Workstation as both host and target and running SunOS or SunView. Host/Target:SPARC under SUNOS For more information, contact:Scott Garren, Alsys, Inc., 67 South Bedford Street, Burlington, MA 01803-5152, USA; Phone: (617) 270-0030 Digital Equipment Corporation (Updated: November 1 992) Digital Equipment Corporation has bindings available for GKS, PHIGS, SQL, and OSF Motif for VAX Ada/VMS. The Ada bindings are provided either as part of a compiler product or the services/facilities that are provided by Digital and its suppliers. Host/Target:DEC VAX under VMS For more information, contact:Mary Anne Cacciola, Digital Equipment Corporation, 110 Spit Brook Road, Nashua, NH 03062, USA; Phone: (603) 881-1028 IBM (Updated: November 1 992) IBM's AIX Ada/6000 product provides a binding to GPEF and IBM AIXWindows (X- Windows ... not Motif). It runs on all models of the IBM RISC System/6000 under the IBM AIX Version 3.2 operating system. See also entries for Systems Engineering Research Corporation (SERC) and Advanced Technology Center (ATC) for Motif, GKS or PHIGS bindings for use with IBM AIX Ada/6000 products. The AIX Ada/6000 licensed programs (5706-291 and 5706-294) consist of an optimizing compiler, a run-time environment, a symbolic debugger, an Ada "makefile" generator for use in automating and minimizing recompilation, Ada library management tools and Ada language bindings to some key AIX subsystems. With the exception of some system-specific aspects of the language, the Ada language for the AIX operating system is source compatible with the Ada language supported by IBM licensed programs in VM/CMS and MVS. Host/Target:IBM RISC System/6000 under the IBM AIX Version 3.2 operating system This product conforms to the following standards: ANSI/MIL-STD-1815A - Ada at current level (1.11) of the ACVC test suite. For more information, contact:Barry Lee, IBM Corporation, 844 Don Mills Road, North York, Ontario, Canada M3C 1V7; Phone: (416) 448-3174; Fax: (416) 448-4810 Objective Interface Systems, Inc. (Updated: November 1 992) Objective Interface Systems, Inc., has an Ada binding to X-windows (OSF Motif) for its Screen Machine~ product. The Screen Machine binding to Motif includes a WYSIWYG drawing tool and an Ada code generator. Host/Target: Sun SPARC/SunOS Rational R1000/Delta HP 9000/7XX; 8X7 IBM RISC System/6000/AIXPC 386/486/ISC UNIX HFSI WIS Workstation PC 286/386/486/MS-DOS PC 386/486/SCO UNIX DEC Ultrix; DEC VMS For more information, contact:Phil Carrasco, Object Interface Systems, Inc. 1895 Preston White Drive, Suite 250, Reston, VA 22091-5448, USA; Phone: (703) 264-1900; Fax: 703-264-1721; email info@ois.com (internet) SL Corporation (Updated: November 1 992) SL Corporation's SL-GMS toolkit includes Ada bindings to GPEF, GPPF, POSIX, SQL, TCP/IP, OSF/Motif, and Open Look. SL-GMS is a toolkit for developing dynamic graphics screens for real-time or highly interactive applications. Non-programmers can design application screens in a standard drawing-tool mode, connect them to real-time data sources and animate screen objects to visualize changing data values. SL-GMS allows the design of custom "GISMOs" to input values or control the application and supports MOTIF, OPEN LOOK and other X toolkit widgets. SL-GMS is used extensively to provide real-time graphics for applications in the fields of manufacturing, process control, network management, avionics and financial tracking. Host/Target:Validated Verdix and DEC compilers support SL-GMS for the following machines as both host and target: DEC-DECstation/ULTRIX 4.0DEC-VAXstation/ULTRIX 4.0 DEC-VAXstation/VMS 5.4 DEC-VAXstation/VMS 5.5 IBM-RS6000/AIX HP-9000/300/UNIX HP-9000/400/UNIX HP-9000/800/UNIX HP-9000/700/UNIX PC-386/IX UNIX PC-386/SCO UNIX PC-386/Lynx PC-386/0S2 PC-386/System 5.4 SGI-4D/IRIX 3.3 Sun-3/SunOS 4.1 SunSPARC/SunOS 4.1 88 Open/BCS Compliant For more information, contact: Mike Meagher, SL Corporation, 240 Tamal Vista Boulevard, Corte Madera, CA 94926, USA Phone: (415) 927-1724; Fax: (415) 927-2931 Sunrise Software International (Updated: May 1 992) Sunrise Software International's product, ezx, is a rapid application development tool that automates the creation of graphical user interfaces for OSF/MOTIF and generates C, UIL, or Ada. ezx provides WYSIWYG screen layout; color, font and pixmap editors; presentation tools and dialog management. A prototype can be developed in hours and using a script language similar to Hypertalk, demonstrated to end-users before the first line of code is written. Then portable C, UIL or Ada can be generated automatically. Ada bindings are provided. The total code required to develop a GUI is reduced by approximately 75%. The appearance and behavior of the GUI is defined in an X resource file which the application loads at run time. This provides explicit separation between the GUI and the computational core of the application. Thus the GUI can be revised without recompiling (and retesting) the application. ezx provides cost savings throughout the software development cycle, from requirements analysis through design, code, test and maintenance. Host/Target:DEC RISC under ULTRIX, DEC VAX under VMS, IBM 386 under UNIX, IBM RS 6000 under AIX, SGI under , SUN SPARC under UNIX For more information, contact:Frederick Sells, Sunrise Software International, 170 Enterprise Center, Middletown, RI 02840, USA; Phone: 401-847-7868 Systems Engineering Research Corporation (SERC) (Updated: November 1 992) SERC's Ada/MOTIF is a complete binding to X Window and OSF/Motif for the Ada programming language that was based in part upon the SAIC/Unisys (STARS) public domain bindings. That work was leveraged as a starting point for this development; many of the bug fixes and additional capabilities beyond the public domain releases in Ada/MOTIF have been incorporated. Most noteworthy are the capabilities included in Ada/Motif for Ada tasking, callback registration, memory leak detection/prevention and capabilities for developing customized widgets. Paramax/STARS considers Ada/Motif to be the commercial version of their STARS bindings, according to SERC. Ada/MOTIF is supported by the ALSYS, VERDIX, SUNAda, IBM Ada, and SGI Ada compilers. Host/Target:SUN 4, HP 300/400, HP 700, IBM RS 6000, SGI, 386 SUN OS 4.1.1, SOLARIS 2.0 (coming), HPUX 8.0, SGI 3.2 & 4.0, IBM ATX 3.2, SCO 3.2 For more information, contact:Theo Kusiolek or Scott Cleveland, Systems Engineering Research Corporation (SERC), 2555 Charleston Road, Mountain View, CA 94043, USA; Phone: 800-ADA-SERC or 415/962-9092; Fax: 415/962-0330; E-mail: Well!sercmail@apple.com. TeleSoft (Updated: November 1 992) TeleSoft's TeleUSE/Ada automates the creation of OSF/Motif graphical user interfaces for Ada applications. It includes a special version of the TeleUse User Interface Management System -- which generates Ada source code -- and Ada bindings to the TeleUSE run-time routines. TeleUse/Ada tools allow a GUI to be prototyped and designed using a WYSIWYG editor and a PDL, and also includes tools for debugging, generating production code and maintaining the GUI. TeleUse/Ada can save the developer up to 90 percent of the time required to hand code X Window System GUIs. Host/Target:SPARC under UNIX, Sun-4 under UNIX TeleSoft's TeleWindows is a set of Ada bindings to the X Window System and OSF/Motif. This includes Xlib, XT, X extensions Library, XT+, X miscellaneous utilities, Motif widget set, XM, MWM, Motif resource manager. It supports X- 11 R4 and is not based on the public domain version. It closely follows the C Xlib syntax and allows Ada applications to co-exist with C applications. Host/Target:IBM System/370 under VM/CMS For more information, contact:Karen Johnson, TeleSoft, 5959 Cornerstone Court West, San Diego, CA 92121-9891, USA; Phone: (619) 457-2700 Verdix (Updated: May 1 992) The Verdix Ada Development System (VADS), is a complete Ada Compiler System offering a fully validated Ada compiler with chapter 13 support. Verdix supplies VADSself and VADScross. VADSself provides a complete toolset for self-targeted applications. It easily interfaces to databases, windowing systems and program management tools. VADScross provides real-time support for host-to-target system development. VADScross produces small and fast object code. VADS is hosted on the largest number of platforms and targets the greatest number of microprocessors. Host/Target:88000 BCS under UNIX, DEC VAX under VMS / ULTRIX / UNIX, DECStation (RISC) under UNIX, DECSystem (RISC) under UNIX, HP 9000 Series 300 under HP-UX (UNIX), IBM PS/2 under AIX (UNIX), IBM RISC System/6000 under AIX, SCO Systems V/386 (ABI) under UNIX, Sun SPARC systems under UNIX, Sun-3 systems under UNIX Verdix AXI provides an Ada binding to the full Motif, Xt, and Xlib libraries. The product works with user-supplied Motif 1.1 and X11R4 libraries regardless of source. Host/Target:DEC RISC under Ultrix, IBM RS6000 under AIX, MIPS under MIPSos, Sun-4 under SunOS, Sys V386 under ISC UNIX, Sys V386 under SCO UNIX For more information, contact:Tim Ruhe, Verdix Corporation, 205 Van Buren, Herndon, VA 22070, USA; Phone: (703) 318-5800 ----------------------------------------------------------------------------- Subject: 106)+ Is there a Poplog binding for Motif? [Last modified: May] Answer: A integrated programming environment consisting of the programming languages Pop-11, Prolog, Standard ML, and Lisp which are compiled to machine code via a common virtual machine. Pop-11 provides a rich interface to the X Toolkit which can be accessed from all other Poplog languages. The OLIT, Motif, and Athena widget sets are supported, in addition to the custom Poplog (Xpw) widget set. XVed provides a sophisticated, customisable multi-window editor. Under OPEN LOOK and Motif the Poplog User Interface (PUI) provides a graphical interface to the Poplog system. High-level Pop-11 libraries allow graph drawing, turtle graphics, and the simple creation of basic button/menu based interfaces. Contact: UK EDUCATION SITES: Poplog Sales. School of Cognitive and Computing Sciences. Brighton. BN1 9QN. England. Phone: +44 (0)273 678188 Email: popsales@cogs.susx.ac.uk USA AND CANADIAN EDUCATION SITES: Computable Functions Inc. 35 South Orchard Drive. Amherst. MA 01002. USA. Phone: (413) 253-7637 ALL OTHER SALES: Integral Solutions Ltd. Unit 3, Campbell Court. Bramley. Basingstoke. Hampshire. RG26 5EG. England. Phone: +44 (0)256 882028 Fax: +44 (0)256 882182 Email: isl@integ.uucp ----------------------------------------------------------------------------- Subject: 107) TOPIC: SPECIFIC PLATFORMS ----------------------------------------------------------------------------- Subject: 108) Is it easy to build Motif for a Sun? Answer: See next question for Solaris 2. No pattern has emerged to problems about compiling Motif on the Sun (although people seem to have a lot of different minor problems), and many reports are that it is straightforward. Read the Motif install instructions (which often have specific reference to Sun installation), light the blue touch paper and just standback. [My experience was that I had to add -D_NO_PROTO for 1.1 on a Sparc OS 4.1, and that was all. Others have added STRINGS_ALIGNED and NO_REGEXP]. ----------------------------------------------------------------------------- Subject: 109) How do I build Motif 1.2.2 on Solaris 2.1 with Sun C? [Last modified: May 93] Prepared by Ric Steinberger. ric@updike.sri.com 4/09/93 What follows is a description of the steps I used to build Motif 1.2.2 on a SUN IPX running Solaris 2.1. Sun's C compiler (2.0.1) was used. Many thanks go to Kaleb Keithley (kaleb@devvax.jpl.nasa.gov) for several useful suggestions. Other people, including OSF staff, especially David Brooks (dbrooks@osf.org), helped as well. My thanks to you all. 1. Build X11R5 from the mit distribution. You need to retrieve the sources from export.lcs.mit.edu (in pub/R5) and patches 1 - 22 (or 23) (in pub/R5/fixes). There are several other sites that contain the X11R5 sources. After installing patch 19, apply PEXlib.tar.Z, also available from export.lcs.mit.edu in pub/R5/fixes. You can apply also R5.Xsun.multi-screen and R5.SunOS5.patch. There are .README files that explain how to patch. Be SURE to read R5.SunOS5.patch.README for details on how to BUILD X11. You probably want to use the ProjectRoot feature in the site.def file in the mit/config directory. You will NEED to edit that file to do that. 2. Obtain the Motif 1.2.2 distribution from OSF (617-621-7300). You may need to first install the 1.2 tape, then the 1.2.1 and finally the 1.2.2 tape. You might want to do a "chmod -R u+w ." after unloading each tape. 3. In the config directory, there are several changes. Some of the changes are based on R5.SunOS5.patch files. A complete set of config files relevant to Solaris have been placed in the anon-ftp account of updike.sri.com in pub/motif/solaris21-motif122-config.tar.Z. They are also available from OSF on their mail response server (available to support contract holders) and they will send them directly to full support contract holders. Decompress and untar this file in your Motif config subdirectory. Copy site.def.sample to site.def, then edit site.def. You will probably want to uncomment the ProjectRoot section and use the same value used in your X11R5 build. Also, you will probably want to use /usr/ucb/install in you installed the UCB compatibility suite. Otherwise you might want to use the install supplied at the end of this memo. [I used the UCB version and can't swear that this works. Bit it should. Put it someplace like /usr/local/bin and chmod +x it.] There are two patches to consider. One fixes a cursor problem in ./lib/Xm/TextF.c. The other removes a Berkeleyism. These patches should probably be consider unofficial at present. Failure to deal with the Berkeleyism (bzero) means you will need to link with -lucb -lelf. This will probably work, but why bother? Furthermore, if you move the Motif binaries to a machine without the ucb compatability suite, you won't have the sharable libs you need. [The actual patches have been censored because they contain OSF source code] Patch 1: In TextF.c there are several places _XmTextFieldDrawInsertionPoint is called. These should be moved two or three lines further down *after* the "if (!XtIsRealized(tf)) return True;" statement. patch 2: The call to bzero in lib/Xm/Visual.c should be replaced by the equivalent call to memset Both these patches can be applied in the ./lib/Xm directory. If you don't have the patch program (how did you build X11?), you can get it in the vendor/cygnus directory of ftp.uu.net, or you can build it from source. Be sure to get the latest version (2.0.12.u8). 4) Use the README-1.2.1 file as a guideline for building motif. I followed directions in the section called, "Using X11R5 Installed Libraries and Header Files." If you make a mistake after your first build attempt, copy Makefile.ini to Makefile before retrying. You may need to do this in the config subdirectory too, depending on what went wrong. 5) After make Makefiles, do make includes, make depend, then make (or as OSF recommends, make -k). This gets as far as motifshell in the demos, which fails to build because O_RDONLY and L_XTND are not defined. O_RDONLY is in fcntl.h (actually <sys/fcntl.h>, but fcntl.h includes this.) L_XTND can be replaced by SEEK_END. SEEK_END is in stdio.h. These two fixes will allow motifshell to build. Note: many MANY compiler warning messages will be generated during the build process. 6) You can go to the demos/xmsamplers directory and do a make there. Other demos may build, or not depending on whatever. . . . 7) make install will do the install. [It will fail at motifshell if you don't fix it, as mentioned above.] You can do a make install in demos/xmsamplers if you want these. 8) If running on a SUN (as opposed to an X term), you will (probably) need to start openwin with something like: openwin -server /usr/X11R5/bin/Xsun [You might want to use an alias for this.] This fixes an annoying problem: The mouse keys stop working after you click on an icon to get the icon menu (on SUNs only, not X terms). The ALT keys still work, if you get stuck. I don't know whether this is a bug in SUN's server or whether it is Motif related. Here is a copy of my .xinitrc: It's not elegant. Sun's default openwin startup file is in: /usr/openwin/lib/Xinitrc. You can copy this to ~/.xinitrc and customize as desired. Obviously, the default behavior is to start the OpenLook environment (boo!). #!/bin/sh # # .xinitrc - OpenWindows startup script. # if [ -f $HOME/.Xdefaults ]; then xrdb $HOME/.Xdefaults # Load Users X11 resource database fi if [ -f $HOME/.Xdefaults.sun ]; then xrdb -merge $HOME/.Xdefaults.sun fi DISPLAY=`hostname`:0.0 export DISPLAY xhost + > /dev/null #xterm -sb -sl 512 -T `hostname` -ls -n `hostname` & xterm -sb -sl 512 -T `hostname` -n `hostname` & mwm & xclock -geometry +1010+0 & xload -geometry +710+5 -fg red & xsetroot -solid salmon & xterm -sb -sl 100 -T CONSOLE_DO_NOT_LOGOUT -C -n console -iconic #wait Here's .Xdefaults.sun, which gives me a more readable font for use with motif on Sun monitors: !Some additional .Xdefaults values specifically for SUN ! ! After loading .Xdefaults, xrdb -merge .Xdefaults.sun ! Mwm*fontList: 8x16 !Mwm*fontList: vtbold !Change as desired. You will probably want to maintain LD_LIBRARY_PATH to something like: /opt/SUNWspro/lib:/usr/ccs/lib:/usr/ucblib:/usr/X11R5/lib:/usr/lib: /usr/openwin/lib. If you use emacs, you will need to leave /usr/openwin/lib there. [This is because you probably, like me, used the distributed version of s-sol2.h, which explicitly refers to windowing libraries as being in the /usr/openwin locations. Yes, I know that emacs/Solaris ought to allow LibXt.so.N.M to be "picked up" from elsewhere, like /usr/X11R5/lib, but the one emacs links with is LibXt.so.4.something, and the mit one is LibXt.so.5.something. So it seems to want the .4 one. Any comments? I'd prefer not to rebuild emacs based on the X11R5 libs because I occassionally need to move the emacs binaries to machines without the mit files.] ----------------------------------------------------------------------------- Subject: 110) What compile errors/warnings might I get in both Sun 3 and Sun 4? Answer: make: Warning: Too many rules defined for target make: Warning: Too many rules defined for target "callbacks.c", line 1530: warning: illegal combination of pointer and integer, op = "callbacks.c", line 1531: warning: illegal combination of pointer and integer, op = "callbacks.c", line 1532: warning: illegal combination of pointer and integer, op = "utils.c", line 73: warning: illegal combination of pointer and integer, op = "utils.c", line 74: warning: illegal combination of pointer and integer, op = "utils.c", line 122: warning: illegal combination of pointer and integer, op = "utils.c", line 123: warning: illegal combination of pointer and integer, op = "utils.c", line 191: warning: illegal combination of pointer and integer, op = "utils.c", line 194: warning: illegal combination of pointer and integer, op = "utils.c", line 195: warning: illegal combination of pointer and integer, op = "utils.c", line 196: warning: illegal combination of pointer and integer, op = "utils.c", line 316: warning: illegal combination of pointer and integer, op = "utils.c", line 334: warning: illegal combination of pointer and integer, op = "utils.c", line 338: warning: illegal combination of pointer and integer, op = "utils.c", line 341: warning: illegal combination of pointer and integer, op = "xmdialogs.c", line 838: warning: illegal combination of pointer and integer, op = "xmeditor.c", line 1152: warning: illegal combination of pointer and integer, op = These warning messages can be ignored. OSF is aware of these warnings. ----------------------------------------------------------------------------- Subject: 111) On a Sun 3, what are the mwm startup error messages about? I get mwm: Invalid accelerator specification on line 7 of specification string mwm: Invalid accelerator specification on line 31 of configuration file Answer: This is because some Sun keyboards do not have an F10 key and some sun workstations which have an F10 key do not have X-servers which recognize it. The F10 key is used by mwm. If the machine does have an F10 key, the user should use xmodmap to tell the server it exists. Otherwise, change the definition of the DefaultWindowMenu in /usr/lib/X11/system.mwmrc (after installation) or in /lib/clients/mwm/system.mwmrc (before installation). Change the accelerator of "Maximize" (it is "Alt<Key>F10)" to something else. Also, you should change the definition of DEFAULTSYSTEMMENU in the file /clients/mwm/WmResource.c in a similar fashion. There is as yet no standard redefinition for F10. ----------------------------------------------------------------------------- Subject: 112) Are there problems making shared libraries on a Sun? Answer: If you use the -pic option you may run out of offset table space. use the -PIC option instead. You may get the message "ld.so: Undefined symbol: __XtInherit" when executing UIL. There is a problem in shared library build when you compare a function variable to a routine name, but don't call the routine. Either, you can build the Xt library nonshared, or you can put a reference to XtToolkitInitialize in the UIL main program (or even include a module that references it). The routine doesn't even have to be called; it just has to be there. ----------------------------------------------------------------------------- Subject: 113) The OpenWindows server hangs when I popup a menu with Button 3. [Last modified: August 92] Answer: This is an OpenWindows problem, but if you have Motif source you can fix your own applications. From Steve Sistare of Thinking Machines Corp.: "Change the 2 calls to XtGrabButton in RowColumn.c such that ButtonReleaseMask | ButtonPressMask is passed for the event mask. Currently, only ButtonReleaseMask is passed. Also, change the owner_event argument to FALSE. " This has not been fixed in Motif as at 1.1.5. ----------------------------------------------------------------------------- Subject: 114) Has anyone made shared libraries on an IBM RS/6000? Answer: From Sakari Jalovaara: There is a problem: Xm redefines VendorShell and the AIX linker put _both_ Xm's and Xt's VendorShell into programs. When an AIX shared library is created as many references inside the library are resolved as possible. If the symbol vendorShellClassRec is defined in libXt and referenced, say, from a function XtFoo() also in libXt, the "ld" run that creates the shared library resolves the reference: XtFoo() -> vendorShellClassRec Then I create the Motif library that has its own vendorShellClassRec and an XmBar() function that uses it; libXm will also contain a resolved reference to vendorShellClassRec: XmBar() -> vendorShellClassRec Finally, I link a program that uses both XtFoo() and XmBar() and the program will end up with _two_ independent "vendorShellClassRec"s: XtFoo() -> vendorShellClassRec [Xt version] XmBar() -> vendorShellClassRec [Xm version] Instant schizo zaphod mode. In reality, vendorShellClassRec is not referenced from functions but from other widget class records. I can't just pull Vendor.o out from the shared Xt (Vendor.o appears to define the only external symbols redefined by libXm) because AIX shared libraries apparently can't contain unresolved external references. If I take out Vendor.o I have to take out every other file that uses symbols defined there - and then files that need those files, etc. I tried it and ended up with three or four object files in libXt and the res non-sharable. I kludged around this by putting all of libXt (minus Vendor.o) into the shared libXm. It isn't a pretty solution but it works - and beats having a statically linked two-megabyte "periodic" demo... ----------------------------------------------------------------------------- Subject: 115) What is the error "Unaligned access in XmString" under Ultrix? Answer: Compile XmString.c with STRINGS_ALIGNED. ----------------------------------------------------------------------------- Subject: 116) TOPIC: KEYSYMS ----------------------------------------------------------------------------- Subject: 117) What is causing the messages "unknown keysym osfDown..."? It happens when I run an application under Motif 1.1 Answer: There is an OSF supplied addition to the /usr/lib/X11/XKeysymDB file. It is found on the release tape and should have been automatically installed if the installation procedure was followed in the Release Notes. You have to copy (or append) lib/Xm/XKeysymDB into /usr/lib/X11. This may require root permission. It is not clear how to fix the problem if you can't do this. The error comes from Xt translation table parsing and can't be fixed in Motif, so if you can't get root permission you may be stuck. The file is not copyrighted so you can install it on other systems. If X has been built so that XKeysymDB is not in this directory, and you don't know where it is looking, run 'strings libX11.a | grep XKeysymDB' to find the path. On a Sun running openwin with shared libraries, you may need to put the path for the library containing XKeysymDB *first* in the path list in LD_LIBRARY_PATH, or it may find the wrong XKeysymDB in the wrong directory. XKeysymDB simply contains the registered keysym values for the OSF keysyms. The OSF values are server-independent. And, all registered keysyms will be included in an XKeysymDB file to be shipped with X11R5. In the meantime (till all systems are X11R5+), a list of the registered keysyms can be found in the X11R4 release in mit/doc/Registry/Xregistry. ----------------------------------------------------------------------------- Subject: 118) What happens if I can't install Motif Keysyms? From: tessi!george@nosun.West.Sun.COM (George Mitchell) Here's what appears to happen if you don't have XKeysymDB in place to define OSF's virtual keysyms: 1. At class initialize time, for a widget (such as XmText) that uses virtual keysyms in its event translation table, all entries which refer to those keysyms fail to parse correctly. In the case of XmText, instead of ending up with a translation table with roughly 90 entries, you end up with one that has 29. 2. XKeysymDB doesn't exist, so you'd assume that KeyPress events will get translated to plain vanilla keysyms, right? WRONG! All Motif widgets install a virtual keysym translator ANYWAY! Consequently, the backspace key (for example) gets translated to the keysym osfBackSpace. 3. Therefore, if you augment or override your widget's translations with translations that refer to plain vanilla BackSpace, they will never be triggered, because you will NEVER see plain vanilla BackSpace, only osfBackSpace. 4. But you can't use osfBackSpace in an event translation entry, because you don't have XKeysymDB installed! Here's how I'm "dealing" with the problem right now: Motif installs its virtual keysym translator by calling XtSetKeyTranslator every time a VendorShell (or subclass) widget is created. So every time I create a shell, I immediately call XtSetKeyTranslator (display, XtTranslateKey) to restore the default translator. No more funny virtual keysyms! Now I can reinstall non- osfKeySym translations and have them work the way I expect. ----------------------------------------------------------------------------- Subject: 119) Why has OSF introduced Keysyms into Motif 1.1? They weren't there in Motif 1.0. Answer: From: ellis@osf.org Virtual Keysyms are meant to provide a consistent keyboard model for Motif applications running in a heterogeneous environment in which proprietary (i.e. vendor specific) non-Motif applications may also be running. First of all, for the sake of the rest of the readers, let's explain why this is an issue: It would be lovely if Motif's translation tables could just use the obvious keysyms predefined by X. For example, there are keysyms for XK_BackSpace, XK_Delete, XK_Left, XK_Right, etc. Shouldn't these be the ones that are used in our translations? Unfortunately, the problem is not so simple. Some specific examples: While most vendors bind XK_BackSpace to the key at the top right of the standard keyboard (often engraved with a leftwards pointing arrow), not all do. In fact, some vendors (including DEC) bind that key to XK_Delete. While most vendors bind the arrow keys to XK_Up, etc, a number of vendors (including Sun, on some servers) bind them to function key keysyms. A simplistic solution would require the use of xmodmap to change the offending bindings. That would work swell in an all Motif environment. However, OSF's goal (not always perfectly achieved) is interoperability. That is, we'd like to make sure that both Motif and non-Motif programs can happily run in the same environment. It is expected that a vendor may have a wide variety of existing X-based software that uses the keysyms as established by that vendor for specific purposes. It is expected that these applications may run at the same time as Motif-based software. Using xmodmap to change keysyms on the server side could "break" the existing applications (or at the very least their documentation) by making some keys unavailable, or by moving the location. So, we chose not to use xmodmap. By the way, though OpenLook uses a different implementation (they recompile their virtual translation tables into actual translation tables), they basically adopted the same approach, presumably for similar reasons. To work properly, the virtual keysym model we implemented depends on Xlib finding XKeysymDB installed appropriately (which standard Motif installation does). This simply defines the keysyms (not the key they are bound to). This unfortunate piece of stupidity is necessary because MIT only includes standard keysyms in keysymdef.h. It should be said that our lives would be made easier if MIT would also see fit to include registered keysyms in keysymdef.h as well. Motif applications determine how to bind virtual to actual keys by looking for either a resource or a property on the root window which describes what to do. Note that this information is on the server side, so that all applications use the same virtual bindings regardless of where they are running. Mwm will happily create the property if it finds a .motifbind file in your home directory when it starts up. (Actually, things generally work even if none of this is done, since if all else fails, the Motif toolkit chooses a virtual bindings table to use based on the identification of the server). The actual implementation of virtual keys is made possible by a hook in the Intrinsics. Undoubtably, the implementation would be simpler and cleaner if virtual key support was more directly supported by the Intrinsics. We will be exploring this possibility in the future. -- Ellis ----------------------------------------------------------------------------- END OF PART FOUR -- +----------------------+---+ Jan Newmarch, Information Science and Engineering, University of Canberra, PO Box 1, Belconnen, Act 2616 Australia. Tel: (Aust) 6-2012422. Fax: (Aust) 6-2015041